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METHOD AND APPARATUS FOR FACILITATING MANAGEMENT OF 
MULTICAST DELIVERY TO MOBILE DEVICES 



TECHNICAL FIELD: 



This invention relates generally to data communication networks operable with mobile 
5 devices or hosts and, more specifically, relates to techniques for providing management 
of multicast message delivery to mobile hosts in a wireless data communications 
network. 



BACKGROUND: 



In order to make use of the multicast technology supported in the wireless network and 
1 0 the access network, multicast services and applications should be managed at the mobile 
station. In other words, the mobile station should be able to differentiate between 
contents in a structured way, so that applications in the mobile station can make use of 
the contents delivered through multicast flow in a meaningful way. It also helps the 
management of a specific multicast flow. For example, when the mobile receives a new 
15 firmware update, a client in the MS should be able to manage this data, which involves 
temporary storage, a check for data integrity, version management, firmware encryption 
if any, and so forth. 

3GPP2 is working on different aspects of multicasting - air interface specifications, Over 
the Air (OTA) messaging aspects and network specifications. There are different 

20 applications of multicast/broadcast. When the same data should be updated to a large 
group of mobile stations, multicasting reduces complexity and cost associated with OTA 
updates. A good example is updating the same firmware to mobile stations, which 
involves a large data transfer. However, without differentiating flows and contents, the 
mobile station would not be able to manage a specific multicast flow and content. 

25 Another example is using multicast/broadcast to update critical software, to avoid 
requiring a recall of mobile stations. In this case it is important that the mobile station be 
able to manage multicast flow and content in a consistent way, which implies a 
standardized method. 
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Some current and future mobile data and message network services require sending the 
same integral unit of data simultaneously to a plurality of mobile hosts such as, for 
example, cellular telephones and/or PDAs having wireless (e.g., IR or RF) 
communications capability. This is referred to as a "multicast" type of operation. A 
5 typical multicast operation may include sending data associated with the provisioning of 
a service, as well as data associated with management during the life cycle of a service. 
Services typically require sending of data to mobile hosts in real time. Data is also 
typically sent when the service is updated. As maybe appreciated, establishing a separate 
end-to-end delivery session for each mobile host would adversely affect the performance 
10 and throughput of networks in the end-to-end path that route the data, as well as in the 
air interface between the network and individual ones of the mobile hosts. 

Current practice delivers data to mobile hosts using low data rate services such as OTA 
teleservices or PUSH, which can be implemented using short message service (SMS) 
techniques, or by using circuit switched or packet switched end-to-end methods that 
15 require a separate connection for each mobile host (a point-to-point approach). However, 
as the use of mobile hosts becomes more widespread, and as more and different types of 
networks are encountered in the end-to-end path between the source of the data and 
mobile hosts, the current techniques will prove to be inefficient with regard to the use of 
network bandwidth and throughput. 

20 Conventional multicast protocols specified for Internet Protocol (IP) and mobile IP 
applications generally take into consideration only the core network and the wireless IP 
network. Examples of such IP-based protocols include DVMRP (Distance Vector 
Multicast Routing Protocol), MOSPF (Multicast Extensions to Open Shortest Path First) 
and PIM-DM (Protocol Independent Multicast-Dense Mode). However, these 

25 conventional techniques are not generally suited for multicast management across 
disparate network types. 

In a wireless network environment a mobile host may not be attached at all times to the 
same network, and the existing multicast routing protocols do not address this situation. 
For mobile services envisioned for the future, many networks may potentially be involved 
30 in routing service-related data to mobile hosts. While the existing IP-based multicast 
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routing protocols, such as those referred to above, can be used for routing within IP 
networks, there is at present no generic mechanism to manage multicast routing in any 
network. For example, there is currently no generic mechanism to manage the multicast 
routing of the data sent from the wireless network and routed through an access network, 
5 such as a Bluetooth™ network. 

Representative U.S. Patents that relate to multicast operation with mobile hosts include 
U.S. 6,477,149 Bl, "Network System and Method of Controlling Multicast Group 
Participation of Mobile Host", Okanoue; U.S. 6,418,138 Bl, "Internet Radio 
Communication System", Cerf et aL; U.S. 6,243,758 Bl, "Internetwork Multicast 
10 Routing Using Flag Bits Indicating Selective Participation of Mobile Hosts in Group 
Activities Within Scope", Okanoue; and U.S. 6,240,089 B 1 , "Method of Multicasting for 
Mobile Host Used in Any One of Subnetworks Connected to One Another", Okanoue et 
al. 

The foregoing U.S. Patents do not cure the existing deficiencies in mobile host multicast 
15 routing protocols with regard to the routing of data through a plurality of different 
network-types. 



SUMMARY OF THE PREFERRED EMBODIMENTS 



The foregoing and other problems are overcome, and other advantages are realized, in 
20 accordance with the presently preferred embodiments of these teachings. 

Embodiments of the invention describe a novel method and apparatus for classifying 
mobile multicast applications and service related flow, so that it can be managed at the 
mobile host. 

A method receives a multicast message flow having content and a flow identification, 
25 checks a type of content, and passes the flow to the appropriate processing entity. 



A method to operate a wireless data communications system includes receiving at a 
device a multicast message flow comprising content and a flow identification; 
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deter minin g a type of content from multicast identification information that comprises 
a part of the flow identification; and passing the flow to an appropriate content processing 
entity. 

A mobile host comprises a wireless transceiver coupled to a controller that operates under 
5 control of a stored program to receive a multicast message flow comprising content and 
a flow identification; to determine a type of content from multicast identification 
information that comprises a part of the flow identification; and to pass the flow to an 
appropriate content processing entity. 

Embodiments of this invention also provide a multicast content server that is coupled to 
10 a plurality of mobile hosts via at least one wireless network The server is operable to 
send a multicast message flow comprising content and a flow identification towards the 
plurality of mobile hosts, where the flow identification comprises multicast identification 
information represented as a data structure. The data structure includes fields such as a 
type identification field specifying a flow type; a provider identification field for 
15 identifying a provider of firmware; a vendor identification for identifying a vendor of 
firmware; and an application identification field for identifying an application in each of 
the plurality of mobile hosts that uses the content delivered in the flow. 

Also in accordance with embodiments of this invention there is provided a data structure 
for the management of a multicast flow having content to a plurality of mobile hosts, 
20 where the data structure comprises a type identification field specifying a flow type; a 
provider identification field for identifying a provider of firmware; a vendor identification 
for identifying a vendor of firmware; and an application identification field for 
identifying an application in the mobile host that uses the content delivered in the flow. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 The foregoing and other aspects of these teachings are made more evident in the 
following Detailed Description of the Preferred Embodiments, when read in conjunction 
with the attached Drawing Figures, wherein: 
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Figure 1 is a generic structuring of BCMCS_FLOWJQD creates classes or categories; 

Figure 2 is a flowchart showing the process in the Mobile Station during the reception 
ofaBCMCS flow; 

Figure 3 shows a non-limiting example of a wireless network that involves a plurality of 
5 wireless communications types, including Wireless IP, a Radio Access Network and a 
Wireless Local Area Network, as well as a multicast service provider, and is one 
exemplary environment wherein the embodiments of this invention may be realized; 

Figure 4 shows a high level view of the BCMCS system; and 

Figure 5 is an exemplary conventional CDMA device information subtree, in accordance 
10 with IOTA DM, and illustrative of the use of a tree structure to represent the multicast 
identification information associated with different multicast flows in accordance with 
certain embodiments of this invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Described herein are methods and apparatus to facilitate the control and management of 
15 broadcast-multicast services (BCMCS) flow in a mobile station, also referred to herein 

as a mobile device and a mobile host The use of the embodiments of this invention aids 

a carrier or service provider in sending data to mobile devices using multicast methods. 

Work is progressing on defining a broadcast-multicast services framework and 

specifications, and there are several aspects of multicast to consider, including multicast 
20 flow and the signaling messages. The embodiments of this invention provide 

enhancements and improvements to known types of existing broadcast-multicast 

frameworks. 

Figure 3 shows a non-limiting example of a wireless network 1 0 that involves a plurality 
of wireless conununications types, including Wireless IP, a Radio Access Network and 
25 a Wireless Local Area Network, as well as a multicast service provider 40 (also referred 
to as a Content Source (CS), and is one exemplary environment wherein the 
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embodiments of this invention maybe realized. 

More specifically, Figure 3 shows an example of the wireless network 10 that includes 
a Wireless IP network 30, a Radio Access Network (RAN) 32 and a Wireless Local Area 
Network (WLAN) 34 that includes a WLAN access point 36. For example, the WLAN 
5 access point 36 can be located at an office, or at a retail establishment, or aboard a cruise 
ship, a bus or some other means of transportation, and users of the WLAN 34 access 
same using the WLAN access point 34. The WLAN access point 34 is connected to the 
wireless IP network 30 over, as an example, a CDMA (high speed link such as CDMA 
lx EV-DV or Ix EV-DO) or via an UMTS air interface 32, or any other air interface 
10 providing connectivity to the wireless IP network 30. A wired IP network 35 is also 
shown coupled to the wireless IP network 30. 

The users are shown as having a plurality of different types of devices 38, which can be 
fixed hosts or mobile hosts 18 (e.g., lap top computers, cellular telephones and PDAs). 

In another embodiment the mobile devices 1 8 may have local RF or IR capability, such 
15 as Bluetooth™ capability, and in this case the WLAN Access Point 36 maybe embodied 
as a Bluetooth™ device or transceiver. 

In general, the various embodiments of the mobile devices 18 can include, but are not 
limited to, cellular telephones, personal digital assistants (PDAs) having wireless 
communication capabilities, portable computers having wireless communication 

20 capabilities, image capture devices such as digital cameras having wireless 
communication capabilities, gaming devices having wireless communication capabilities, 
music storage and playback appliances having wireless communication capabilities, 
Internet appliances permitting wireless Internet access and browsing, as well as portable 
units or terminals that incorporate combinations of such functions. Non-mobile (fixed) 

25 devices, such as desk-top PCs, may also benefit from the use of the embodiments of this 
invention. 

The construction of an exemplary one of the mobile hosts 1 8 is also shown in Figure 3, 
where the mobile host 1 8 includes a controller 1 8 A, such as one or microprocessors, and 
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a memory 1 8B that stores data, including program instructions for directing the controller 
in execute methods in accordance with this invention, such as the method depicted in Fig. 
2 and described in further detail below. The mobile host 18 typically also includes a 
suitable transceiver 1 8C (e.g., a cellular and/or WLAN RF transceiver) and antenna 1 8D. 
5 In optical embodiments of this invention the transceiver 18C and antenna 18D are 
modified appropriately. Typically a suitable user interface (UI) 18E is provided, such as 
a keypad, or keyboard and/or touch screen and a display. 

In the non-limiting embodiment depicted in Figure 3 the service provider 40 (a provider 
10 of a multicast service) coupled to the IP network 35 may announce the availability of a 
multicast service. Each device 38 may discover the multicast service, and may have the 
opportunity to join the multicast session. This can involve downloading software and/or 
updating already installed software, as non-limiting examples. The multicast service 
provider 40 may be part of the serving network, or an independent entity (possibly a 
15 subscription-based serving entity). 

Figure 4 shows a high level view of the BCMCS, and is taken from a document: 3GPP2 
S.R0083-0, Version 1 .0, Version Date: 16 October 2003, "Broadcast-Multicast Service 
Security Framework". In this view of the BCMCS system it can be seen that there can be 
multiple RANs 32 each serviced by a BCMCS-capable Packet Data Support Node 
20 (PDSN) 30A. A single forward channel from each illustrated cellular system Base 
Transceiver Station (BTS) sends the same data simultaneously (broadcasts) to multiple 
mobile stations or mobile hosts 18. 

When the mobile host 1 8 receives data in a multicast flow, in order to make use of the 
25 data, it has to be managed. Also, in order to make efficient use of the received data, 
various BCMCS flows should be correctly managed. BCMCS flow is identified by the 
conventional BCMCS_FLOW_ID field, which can be a 1 6 bit, 24 bit or 32 bit identifier. 
The number of BCMCS flows is specified by NUM_BCMSJFLOWS. 

Certain mobile applications require the carrier or multicast service provider 40 to perform 
30 large-scale updates of the same data. One example is updating firmware, which is 
common to all devices 38 of a specific make and model. If the BCMCS framework is 
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used for the delivery of firmware updates, then the mobile host 18 should be able to 
identify the data* This is because each piece of data received at the mobile host 1 8 may 
have a different use. The firmware may require an additional security mechanism, such 
as decryption, as it may be critical software in the mobile host 1 8. The mobile host 1 8, 
5 after receiving the data, should channel it to the entity in the mobile host 1 8 handling the 
firmware. Similarly another software may have a different requirement, such as software 
related to an application. In another case, the flow may include a video stream. As such, 
it can be appreciated that it is important to differentiate BCMCS flows from one another, 
and what is received in each flow. Prior to this invention, there was not standard way (no 
10 non-network specific way) of performing this function. 

Differentiating content in the BCMCS flow 

The BCMCS JFLOWJtt) is used to identify a BCMCS session in different phases of the 
service. This parameter is also included in a BCMCS Service Parameters message 
(BSPM), which is a signaling message sent on the paging channel or a Broadcast Control 
15 channel. Similarly, BCMCS_FLOWJD can be included in other messages. In order to 
differentiate the contents of each BCMCS flow, the BCMCS JFLOWJ© is preferably 
carefully designed in accordance with embodiments of this invention. A generic 
structuring of the BCMCS JETLOWJDD that creates classes or categories of content is 
shown in Figure 1, and is described as follows. 

20 Type 101: The Type field 101 specifies the generic content type in the BCMCS flow. 
Examples of the type can be, but are limited to, firmware, application software, video, 
audio, and so forth. 

Provider ID 102: Identifies the provider of the firmware. This is the identification of the 
service provider 40, and may identify a carrier updating firmware. The Provider ID 102 
25 may be the ID of the server that is managing the firmware updates. 

Vendor ID 1 03 : The unique ID of the Vendor of the firmware. This can be taken from the 
Electronic Serial Number (ESN) or the Mobile Equipment Identifier (MEID), as two non- 
limiting examples. 
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Application ID 104: This is the identifier of the application in the mobile device 38, 
which uses or consumes the content delivered in the BCMCS flow. 

Time 105: The Time 105 is an optional field whereby it becomes possible to send the 
time when a specific multicast/ broadcast flow begins, as part of the BCMCSJFLOWJtD, 
5 or as a separate parameter in the BSPM. 

The above selection of parameters can also help the mobile to develop suitable display 
for multicast services. For example, using content type, time, application id etc., a menu 
of all BCMCS flows can be displayed to the user via the user interface 18E. 

Process in the mobile host 18 
10 Reference is made to Figure 2, which is a logic flow diagram showing the process in the 
mobile host 18 during the reception of a BCMCS flow. Processing of firmware has 
requirements different from other software related to applications and services. 
Processing of received firmware in the flow diagram may include firmware integrity 
check, decryption, descrambling, backing up old firmware and updating the firmware. 

15 Referring to Figure 2, a BCMCS Flow is received at step 210, and the 
BCMCS JFLOW_ID is checked at step 220. A check is made for the type of content at 
step 230 (Type field 101 is examined), and if the type indicates firmware, the flow is 
passed to a firmware processing entity in the mobile host 1 8 (step 240). If not firmware, 
the content type 101 is checked for a content type that maybe supported (step 250). If it 

20 is a type that is supported, the flow is passed to appropriate processing entity for that 
particular content type at step 260 (e.g., audio/visual content is passed to an audio/visual 
player of the mobile host 18). If the content is not a type that is supported, then an error 
message is issued, possibly to the user via the UI 18E, at step 270. 

Another use case of differentiating BCMCS flow is in Quality of Service (QoS) 
25 management. QoS parameters can be different for different types of BCMCS content. 
Differentiating contents aids in applying and/or managing various QoS settings. 



While this invention has been described in the context of presently preferred 
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embodiments, it is possible that those skilled in the art may derive various changes to the 
< teachings of this invention, when guided by the foregoing disclosure. As but a few non- 
limiting examples, in one embodiment the mobile host 1 8 can request information about 
a multicast program from the content server 40. In another embodiment the multicast 
5 identification information shown in Figure 1 can include one or more security parameters. 
In a further embodiment, the content server 40 may send a list of multicast flows with the 
identification information. In another embodiment the user can select a multicast program 
based on flow identification information by using the UI 18E. In a still further 
embodiment, the user, or the mobile host 18 automatically, can selectively request 
10 information about a multicast content flow, such as the multicast update of firmware 
and/or application data. In another embodiment the multicast identification information 
shown in Figure 1 can be represented using Extended Markup Language POVEL), or 
Synchronization Markup Language (SyncML), for transmission over-the-air (OTA). 

In a still further embodiment the multicast identification information associated with 
15 different multicast flows can be represented and stored in a tree-like structure associated 
with a management framework, such as in an Open Mobile Alliance (OMA) Device 
Management framework. Reference in this regard may be had, as an example, to 3GGP2 
IOTA (IP-based Over the Air) device management documentation. For example, Figure 
5 shows a non-limiting example of a prior art management tree for managing CDMA 
20 mobile stations using IOTA DM, specifically a CDMA device information (Devinfo) 
subtree. In Figure 5 Devld is the fixed identifier of the device (e.g., ESN or MEED), 
CDMAProtPref specifies a current preference to describe objects andprovides backwards 
compatibility with TIA/EIA-683 standard features, CDMAProvCap specifies legacy 
features supported by the device, and CDMABandModCap is a field to describe the band 
25 and mode capabilities of the device. The subtree shown in Figure 5 is provided for 
illustration purposes, as this structure would be modified as need to accommodate the 
multicast identification information associated with different multicast flows, in 
accordance with embodiments of this invention. 

It should thus be appreciated that the foregoing and other modifications to the teachings 
in accordance with this invention should be found to fall within the scope of the teachings 
of this invention, and are subsumed thereby. 
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